/*	Interactive Gravitational Simulator
	Project: IGS Core
	File: Configuration.h
	Author: Mike Bantegui <mbante2@gmail.com>, Hofstra University 
	Copyright (C) 2012 - 2013 Mike Bantegui

	This file is part of the IGS software package for simulating
	the N-Body problem in real-time. This was developed as part
	of a departmental honors thesis project at Hofstra University
	in the Spring 2012 semester.

	IGS is free software; you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation; either version 2 of the License, or
	(at your option) any later version.

	IGS is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program; if not, write to the Free Software
	Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
*/

#ifndef IGS_CONFIGURATION_H
#define IGS_CONFIGURATION_H

namespace IGS
{

// DerivativeCount controls the maximum number of derivatives (acceleration, etc.)
// that will be computed for use in the integration step. This parameter represents
// the largest space vs time vs accuracy tradeoff that can be made within IGS.
// By adjusting DerivativeCount, the simulation stores more derivatives (requiring 
// more memory and computation) but has higher order integrators available.

// Count | % Memory Inc. | % CPU Inc. | Integrators Available
// -----------------------------------------------------------
// 1     |      0.0%     |     0.0%   | Euler, Euler-Trapezoid, Symplectic-Euler, Leapfrog
// 2     |     30.7%     |    18.1%   | Hermite
// 3     |     61.5%     |    54.4%   | Hermite-6
// 4     |      N/A      |     N/A    | Hermite-8 (not implemented)

#define DerivativeCount 3

// The following controls the maximum number of terms included in the multipole
// potential expansion of the potential. When greater than zero, this increases
// the accuracy of the potential calculation from first order up through sixth
// order in exchange for increased memory consumption and CPU usage. It is highly
// recommended that at least the first order expansion is used. Higher order terms
// become prohibitively expensive very quickly.

// Terms | Potential Accuracy | % Memory Inc. | % CPU Inc. 
// --------------------------------------------------------
// 0     |      O(|dr|^1)     |     0.0%      |    0.0%
// 1     |      O(|dr|^3)     |    25.7%      |    7.5%
// 2     |      O(|dr|^4)     |    61.4%      |   62.4%
// 3     |      O(|dr|^6)     |   114.1%      |  278.1%

#define MultipolePotentialTerms 1


// PlummerSoftening enables the use of the standard Plummer softening kernel of
// 1 / (r^2 + e^2)^(3/2). Otherwise, the softening kernel used is 1 / (r + e)^3
// The Plummer softening kernel more closesly estimates the unsoftened gravity,
// so it's use is strongly recommended. For softening parameters on the order of
// O(1), the integrated ratio of the magnitude of unsoftened gravity to softened
// gravity falls off as roughly 1 / softening. The non-standard softening kernel
// falls off much more rapidly as a 1 / softening^2.
#define PlummerSoftening

// The following parameter forces the K-d tree generated to be fully balanced.
// This guarantees that the tree will be of maximum depth Log2(N). The time
// complexity for building the tree will be of order O(N Log N). If disabled,
// the tree build time will be of order O(n) however it will not always guarantee
// the optimal subdivision of a given NBodySystem.
#define BalancedKDTree

// The BalancedOctree option attempts to enforce a balanced Octree by subdividing
// bodies about the center of mass instead of the geometric center of the bounding
// box containing the bodies. Octrees built about the center of mass tend to have
// better accuracy characteristics as they cluster bodies more efficiently. The
// option has a negligible impact on the speed of the build step but can impact
// the speed of the evaluation step.
#define BalancedOctree

// If PoolAllocator is defined, then the underlying tree data structures
// will use a memory pool to manage allocations. This requires slightly
// more setup work on the part of the consumer of this class, as it requires
// a call to SetPoolSize to be made. If this call is not made, the tree will
// be unusable. The use of pool allocation is more efficient for large system
// sizes.
//#define PoolAllocator

// EvaluationCorrectionOrder allows the Simulator be used within P(EC)^N mode,
// wherein the Evaluate-Correct step is repeated N times to improve the estimate
// of the acceleration. In informal testing, using P(EC)^N mode improves error
// by as much as a factor of 10 per extra EC step. Testing has not yet been done
// to determine if P(EC)^2 with twice as large time steps provides better accuracy
// than PEC with half as large time steps.
#define EvaluationCorrectionOrder 1

// UsePECE allows the simulator to run in Predict-Evaluate-Correct-Evaluate mode.
// PECE mode uses the same reasoning as P(EC)^N in that it performs an extra
// evaluation step after the correct step in order to obtain a more accurate estimate
// of the forces and energies for the next integration step. PECE mode is very similar
// to P(EC)^N mode, except that it only performs the final evaluation step without
// the correct step. This option can help improve the accuracy of the simulation like
// P(EC)^N mode, but to a lesser extent. It is sometimes useful to use PEC + PECE,
// or P(EC)^2 + PECE to obtain higher accuracy than plain PEC or PEC(N)^2 mode.
//#define UsePECE

}

#endif